The CI marks this as "unstable", probably because there are 6 new warnings (https://build.ros2.org/job/Rpr__common_interfaces__ubuntu_noble_amd64/24/gcc/new/) from the "deprecated-declarations" that are introduced by this PR. @tfoote I guess keeping on using the deprecated encodings is not an option anymore?

You need to explicitly suppress those warnings that are known to the developer for backwards compatibility.

https://stackoverflow.com/questions/13459602/how-can-i-get-rid-of-deprecated-warnings-in-deprecated-functions-in-gcc

Luckily clang will pick up the GCC ones

https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas

I wrapped the code that is still using the deprecated marked encodings inside the GCC diagnostic pragma:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
[...]
#pragma GCC diagnostic pop

@tfoote Can you have a look at this again?

@tfoote Is now a good time to have a look at this? :-)

Please make sure to run CI on these PRs; this one has caused regressions.

Besides causing warnings on all platforms, the pragmas used here for GCC do not work on Windows. I'm going to revert this commit, because it causes too many problems right now.

Please make sure to run CI on these PRs; this one has caused regressions.

The CI on this PR passed (https://build.ros2.org/job/Rpr__common_interfaces__ubuntu_noble_amd64/27/).

Of course, this CI does not test other repos and as far as I understood, causing warnings such as warning: ‘sensor_msgs::image_encodings::YUV422’ is deprecated: use sensor_msgs::image_encodings::UYVY is expected and was the reason to deprecate the encodings before they are removed.

If we do not deprecate them before removal, how can I proceed with this? If the CI in this repo is not sufficient, how do we know if a PR can be merged?

Of course, this CI does not test other repos and as far as I understood, causing warnings such as warning: ‘sensor_msgs::image_encodings::YUV422’ is deprecated: use sensor_msgs::image_encodings::UYVY is expected and was the reason to deprecate the encodings before they are removed.

We do not allow warnings in the core. So if something is deprecated here, we need to update the rest of the core that depends on it. Additionally, the #ifdef guards here did not work on Windows, and caused additional regressions there.

If we do not deprecate them before removal, how can I proceed with this?

We should deprecate them before removal.

If the CI in this repo is not sufficient, how do we know if a PR can be merged?

We have CI jobs (which you can see in #256 (comment)) which do test PRs against the entire core. Those need to be run before we merge anything in (we do that for all PRs).

We have CI jobs (which you can see in #256 (comment)) which do test PRs against the entire core. Those need to be run before we merge anything in (we do that for all PRs).

Are those triggered automatically for PRs to this repo? If so, this did not happen last time. If not, how do I trigger this for a new PR?

Are those triggered automatically for PRs to this repo?

No, they need to be manually run by a maintainer.

Ok. I guess I will then run those locally for now and will ask again once I submit a PR again.

For this deprecation change to be accepted again, is it sufficient if all of https://github.com/ros2/ros2/blob/rolling/ros2.repos builds on Linux and Windows without warnings?